Fix Front script injection #1054
Conversation
…e script now appends to the `<body>` element as recommended by Front, and a duplicate `appendChild` call has been removed.
|
commit: |
|
👇 Not sure what I can do about that failing Check integrations check (looks like it wants 1Password access?) |
|
Hi @dugjason Thanks for investigating this with us! And thanks for starting this PR. I’ve tested this out, but it’s still not working. After debugging a little more, it looks like it’s coming from the It’s currently injecting It looks like updating it to CleanShot.2025-11-18.at.18.18.17.mp4 |
|
Good find - thanks @addisonschultz That being said - the way the chat widget is currently implemented (loading in the |
|
@dugjason yes - thanks again for making this PR to fix the script injection. The 1password check is an ongoing issue we have from external PRs, I’ve verified the changes are valid and it’s good to go since the other checks are passing. I will leave this PR open for now, in case we have a resolution from the product team soon? If we need to make any additional changes here? |
|
Thanks Addison - sounds like a plan. We'll get back to you as we have news |
|
Hi @dugjason - do you have any updates for us? |
|
Hey @addisonschultz , I think it's resolved 🤞 |
|
Hi @dugjason - It does look like it’s fixed! https://support.backpack.exchange/ Just to clarify, this was something you updated on the Front script side, right? |
|
@dugjason actually - apologies, backpack is still running into the issue. I’m doing some more testing on my end too: 
|
|
@dugjason any update? 🙏 We’d love to get this resolved for Backpack if possible |
|
Hey @addisonschultz @dugjason, We've been waiting on this fix for a while and wanted to help unblock it. Since the ((d, s) => {
const chatId = '<TO_REPLACE>';
d = document;
s = d.createElement('script');
s.src = 'https://chat-assets.frontapp.com/v1/chat.bundle.js';
s.async = 1;
s.onload = () => {
if (window.FrontChat) {
window.FrontChat('init', { chatId: chatId, useDefaultLauncher: true });
}
// Workaround for Front's color-scheme bug
// Front's widget uses color-scheme: normal which doesn't respect page color schemes
// This override allows proper light/dark mode support
const styleOverride = d.createElement('style');
styleOverride.textContent = `
[data-front-chat-container],
[data-front-chat-container] iframe,
#front-chat-container,
#front-chat-container iframe {
color-scheme: light dark !important;
}
`;
d.head.appendChild(styleOverride);
};
// Append to body (just before closing </body> tag) as per Front's documentation
d.getElementsByTagName('body')[0].appendChild(s);
})(window, document);This injects a CSS override after the widget loads, forcing I've also filed an issue on the Front SDK repo to track the upstream fix: frontapp/front-chat-sdk#32 Happy to submit a PR with this change if that would be helpful! |
|
Hey @sammassey-bp thanks for trying to implement this. I was trying to test this out, but unfortunately this route won’t work as the widget is injected dynamically after the page loads - so this css won’t reach the widget. This will be need to be implemented by @dugjason and the Front team to the actual widget unfortunately. I did notice a small workaround that might be of use for you right now - If you enable the toggle switcher (light/system/dark) on your docs, the widget respects the theme as the user switches. It will also respect the dark mode preference if set by the user. Maybe not ideal, but a workaround that would get rid of the annoying white box around the widget. All you’ll need to do is enable the light/dark mode toggle in customization settings, and make sure you have an appropriate light mode color scheme set up. Here’s an example: https://addisons-sandbox.gitbook-staging.io/my-first-site/ |
3 participants
Fixes script injection issue.
The script now appends to the
<body>element as recommended by Front, and a duplicateappendChildcall has been removed.Refer to Front docs https://help.front.com/en/articles/2049#install_front_chat_on_your_website